home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-iab-multiprotocol-00.txt < prev    next >
Text File  |  1993-10-28  |  14KB  |  311 lines
  1.  
  2. Internet Architecture Board                        Barry Leiner
  3. INTERNET DRAFT                                     USRA
  4. <draft-iab-multiprotocol-00.txt>           Yakov Rekhter
  5.                            IBM
  6. Expiration Date: April 1994                        October 1993
  7.  
  8.  
  9. The MultiProtocol Internet
  10.  
  11.  
  12. Status of this Memo
  13.  
  14. This document was prepared by the authors on behalf of the IAB. It
  15. is offered by the IAB to stimulate discussion.
  16.  
  17. This document is an Internet Draft. Internet Drafts are working
  18. documents of the Internet Engineering Task Force (IETF), its
  19. Areas, and its Working Groups. Note that other groups may also
  20. distribute working documents as Internet Drafts.
  21.  
  22. Internet Drafts are draft documents valid for a maximum of six
  23. months. Internet Drafts may be updated, replaced, or obsoleted by
  24. other documents at any time. It is not appropriate to use Internet
  25. Drafts as reference material or to cite them other than as a
  26. "working draft" or "work in progress". Please check the
  27. 1id-abstracts.txt listing contained in the internet-drafts Shadow
  28. Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net,
  29. ftp.nisc.sri.com, or munnari.oz.au to learn the current status of
  30. any Internet Draft.
  31.  
  32. Abstract
  33.  
  34. There has recently been considerable discussion on two topics:
  35. MultiProtocol approaches in the Internet and the selection of a
  36. next generation Internet Protocol. This document suggests a
  37. strawman position for goals and approaches for the IETF/IESG/IAB
  38. in these areas. It takes the view that these two topics are
  39. related, and proposes directions for the IETF/IESG/IAB to pursue.
  40.  
  41. In particular, it recommends that the IETF/IESG/IAB should
  42. continue to be a force for consensus on a single protocol suite
  43. and internet layer protocol. The IETF/IESG/IAB should:
  44.  
  45.  - maintain its focus on the TCP/IP protocol suite,
  46.  
  47.  - work to select a single next-generation internet protocol and
  48.    develop mechanisms to aid in transition from the current IPv4, and
  49.  
  50.  - continue to explore mechanisms to interoperate and share
  51.    resources with other protocol suites within the Internet.
  52.  
  53. 1.      Introduction
  54.  
  55. The major purpose of the Internet is to enable ubiquitous
  56. communication services between endpoints. In a very real way, the
  57. Internet IS inter-enterprise networking. Therefore, the issue of
  58. multiprotocol Internet is not just the issue of multiple network
  59. layers, but the issue of multiple comparable services implemented
  60. over different protocols.
  61.  
  62. The issue of multiprotocol Internet is multidimensional and should
  63. be analyzed with respect to two simultaneous principles:
  64.  
  65.  - It is desirable to have a single protocol stack. The community
  66.    should try to avoid unconstrained proliferation of various
  67.    protocol stacks.
  68.  
  69.  - In reality there will always be more than one protocol stack.
  70.    Presence of multiple network layers is just one of the corollaries
  71.    of this observation, as even within a single protocol stack,
  72.    forces of evolution of that stack will lead to periods of multiple
  73.    protocols. We need to develop mechanisms that maximize the
  74.    services that can be provided across all the protocol stacks
  75.    (multiprotocol Internet).
  76.  
  77. 2.      Background and Context
  78.  
  79. 2.1.    The MultiProtocol Evolutionary Process
  80.  
  81. In an IAB architectural retreat held in 1991  [Cla91] , a dynamic
  82. view of the process of multiprotocol integration and accommodation
  83. was described, based on the figure below.
  84.  
  85. --------
  86.  
  87. ---------------             --------------
  88. !             !             !            !
  89. !             !             ! Interop-   !
  90. ! Primary     ! >>>>>>>>>>> ! erability  !>>>>>
  91. ! Protocol    !             !            !    v
  92. ! Suite       !             --------------    v
  93. !             !                               v
  94. !             !                               v
  95. !             !             --------------    v
  96. !             !             !            !    v
  97. !             ! >>>>>>>>>>> !  Resource  !    v
  98. !             !             !  Sharing   !>>>>v
  99. !             !             !            !    v
  100. ---------------             --------------    v
  101.       ^                                       v
  102.       ^      --------------                   v
  103.       ^      !            !                   v
  104.       <<<<<<<! Harmonize  !<<<<<<<<<<<<<<<<<<<<
  105.          !            !
  106.          !            !
  107.          --------------
  108.  
  109. Figure 1: MultiProtocol Evolution Process
  110.  
  111. ----------
  112.  
  113. The figure describes the process from the perspective of a
  114. community working on a single primary protocol suite (such as the
  115. IETF/IESG/IAB working on the TCP/IP protocol suite.) (Note: It
  116. must be kept in mind throughout this paper that, while the
  117. discussion is oriented from the perspective of the IETF/IESG/IAB
  118. and the TCP/IP protocol suite, there is a complementary viewpoint
  119. from the perspective of each of the communities whose primary
  120. focus is on one of the other protocol suites.) There are other
  121. protocol suites (for example, IPX, OSI, SNA). Although the primary
  122. emphasis of the community is developing a system based on a single
  123. set of protocols (protocol suite), the existence of other protocol
  124. suites demands that the community deal with two aspects of
  125. multiprotocolism. The first is interoperability between the
  126. primary protocol suite and other protocol suites. The second is
  127. resource sharing between the primary protocol suite and other
  128. protocol suites. Both interoperability and sharing may happen at
  129. multiple levels in the protocol suites.
  130.  
  131. Achieving interoperability and resource sharing is difficult, and
  132. often unanticipated interactions occur. Interoperability can be
  133. difficult for reasons such as lack of common semantics. Resource
  134. sharing can run into problems due to lack of common operational
  135. paradigms. For example, sharing bandwidth on a link may not work
  136. effectively if one protocol suite backs off in its demands and the
  137. other does not. Interoperability and resource sharing both require
  138. cooperation between the developers/users of the different protocol
  139. suites. The challenge in this area, then, is to develop mechanisms
  140. for interoperability and resource sharing that have minimal
  141. negative affect on the primary protocol suite.
  142.  
  143. The very attempts to achieve interoperability and resource sharing
  144. therefore lead to an attempt to bring the multiple protocol suites
  145. into some level of harmonization, even if it is just to simplify
  146. the problems of interoperability and sharing. Furthermore, the
  147. communications between the communities also leads to a level of
  148. harmonization. These processes, together with the normal process
  149. of evolution, lead to changes in the primary protocol suite, as
  150. well as the other suites.
  151.  
  152. Thus, the need for new technologies and the need to accommodate
  153. multiple protocols leads to a natural process of diversion. The
  154. process of harmonization leads to conversion.
  155.  
  156. While this discussion was oriented around the relation between
  157. multiple protocol suites, it can also be applied somewhat to the
  158. process of evolution within the primary protocol suite. So, for
  159. example, as new technologies develop, multiple approaches for
  160. exploiting those technologies will also develop. The process then
  161. hopefully leads to a process of harmonization of those different
  162. approaches
  163.  
  164. 2.2.    The Basis of the Internet
  165.  
  166. The rapid growth of the Internet has resulted from several forces.
  167. Some of them are "practical", such as the bundling of TCP/IP with
  168. Berkeley Unix and the early decision to base NSFNet on TCP/IP.
  169. However, we believe that there is a more fundamental reason for
  170. this growth. The Internet (and the TCP/IP protocol suite) were
  171. targeted at Inter-Enterprise Networking. Although the availability
  172. of TCP/IP on workstations and the desire to have a single
  173. environment serve both intra- and inter-enterprise networking led
  174. to the use of TCP/IP within organizations, the major contribution
  175. of the Internet and TCP/IP was to provide to user communities the
  176. ability to communicate with other organizations/communities in a
  177. straightforward manner using a set of common and basic services.
  178.  
  179. Fundamental to this ability was the fact that the Internet was
  180. based on a single, common, virtual network service (IP) with a
  181. supporting administrative infrastructure. This allowed a
  182. ubiquitous underlying communication infrastructure to develop
  183. serving the global community, upon which a set of services could
  184. be provided to the user communities. This also allowed for a large
  185. market to develop for application services that were built upon
  186. the underlying communications.
  187.  
  188. An important corollary to having a single common virtual network
  189. service available to the end user (open network service) is that
  190. the selection of applications becomes the province of the end-user
  191. community rather than the intermediate network provider. By having
  192. this common underlying infrastructure, user communities are able
  193. to select their desired/required application services based on
  194. their unique needs, with assurance that the intermediate
  195. networking service will support their communication requirements.
  196. We believe that this has been of considerable importance in the
  197. success of the Internet.
  198.  
  199. 3.      Directions for Multiprotocolism
  200.  
  201. Over the past few years, with the increasing scope of the
  202. Internet, has come an increasing need to develop mechanisms for
  203. accommodating other protocol suites. Most techniques have fallen
  204. into the regime of either interoperability (techniques that allow
  205. for communications between users of different protocol suites) or
  206. resource sharing (allowing common resources such as links or
  207. switches to jointly service communities using different protocol
  208. suites.) It must be noted that such techniques have been quite
  209. limited, with interoperability happening primarily at application
  210. layers and resource sharing happening to limited extent.
  211.  
  212. This need to deal with multiple protocol suites has led to
  213. discussion within the community concerning the role of the
  214. IETF/IESG/IAB regarding the TCP/IP protocol suite versus other
  215. protocol suites. Questions are asked as to whether the TCP/IP
  216. protocol suite is the sole domain of interest of the IETF/IESG/IAB
  217. or if the community needs also to deal with other protocol suites,
  218. and if so, in what manner, given these other protocol suites have
  219. their own communities of interest pursuing their development and
  220. evolution.
  221.  
  222. The answer to this question lies in understanding the role of the
  223. IETF/IESG/IAB with respect to the process described above (Figure
  224. 1). The continued success of the Internet relies on a continued
  225. strong force for convergence, making sure that the primary
  226. protocol suite (TCP/IP) is successful through an evolutionary
  227. process in accommodating both the changing user requirements and
  228. emerging technologies.
  229.  
  230. Since this process requires a continued effort to accommodate
  231. other protocol suites within the overall Internet, efforts at
  232. interoperability and sharing must continue. Thus, we can summarize
  233. the directions for the IETF/IESG/IAB as two-fold:
  234.  
  235. - Have as a primary focus the evolution of the primary protocol
  236.   suite (TCP/IP), acting as a force for convergence at all times
  237.   towards a single set of protocols, and
  238.  
  239. - Make provision for other protocol suites within the global
  240.   Internet through mechanisms for interoperability and resource
  241.   sharing.
  242.  
  243. 4.      Next Generation Internet Protocol
  244.  
  245. The principles described above for multiprotocolism can also be
  246. applied to the discussions regarding the next generation internet
  247. protocol. Currently, there are several candidates for IPng, which
  248. raises the question of how to deal with multiple protocols at that
  249. level. We note that even if just one is selected, there is an
  250. issue involved in transitioning from IPv4 to IPng.
  251.  
  252. Selection of a single Internet protocol is not the only way of
  253. dealing with this issue. Even if a layer of ubiquity is required
  254. (such as that provided currently by IP), we might consider
  255. providing ubiquity at a different layer. For example, we could
  256. imagine having a common transport protocol running over multiple
  257. internet protocols. We also could imagine achieving
  258. interoperability by use of common application services (such as
  259. directory services) running over diverse communication services
  260. (both transport and network layers).
  261.  
  262. These alternatives do not provide the considerable benefits of a
  263. single internet protocol, and therefore would be undesirable.
  264. Having a single internet protocol provides a common communication
  265. infrastructure across the various networks, thereby achieving the
  266. following:
  267.  
  268. - Communities of end users can select their desired applications,
  269.   independent of the technologies used to support the intermediate
  270.   networks.
  271.  
  272. - The common underlying infrastructure provides a common
  273.   marketplace upon which application developers can create new and
  274.   exciting applications. Installation of these applications does not
  275.   require end users to select a corresponding network protocol
  276.   (although some advanced applications may require enhancements,
  277.   such as high-bandwidth approaches).
  278.  
  279. Thus, the community (IETF/IESG/IAB) should continue to act as a
  280. force for convergence by selecting a single next generation
  281. Internet protocol and developing methods to ease the transition
  282. from IPv4 to IPng. Specifically, at the applications layer, it is
  283. desirable to promote different approaches and "let the marketplace
  284. decide." However, it is unacceptable to treat the internet
  285. protocol layer in the same way.
  286.  
  287. 5.      Conclusion
  288.  
  289. Historically, the IETF/IESG/IAB has acted as a strong force for
  290. the development of the Internet by acting as a force for
  291. convergence on and evolution of a single primary protocol suite.
  292. This has served the community well, and this approach should be
  293. continued for the future. In particular, the IETF/IESG/IAB should:
  294.  
  295.  - maintain its focus on the TCP/IP protocol suite,
  296.  
  297.  - work to select a single next-generation internet protocol and
  298.    develop mechanisms to aid in transition from the current IPv4, and
  299.  
  300.  - continue to explore mechanisms to interoperate and share
  301.    resources with other protocol suites within the Internet.
  302.  
  303. 6.      References
  304.  
  305.  [Cla91]        D. Clark, L. Chapin, V. Cerf, R. Braden, and R. Hobby,
  306. Towards the Future Internet Architecture. RFC No. 1287.
  307. 1991.
  308.  
  309.  
  310.  
  311.